Cours 6

Sauvegardes et restaurations 💾

Les sauvegardes constituent un élément fondamental de tout déploiement informatique sérieux. Dans l'environnement de virtualisation Proxmox VE, la sauvegarde devient encore plus critique car elle protège non seulement les données, mais également l'infrastructure virtuelle complète.

Pourquoi sauvegarder dans un environnement virtualisé ?

• Protection contre les pannes matérielles du serveur hôte
• Récupération rapide après une corruption de données
• Migration vers de nouveaux équipements
• Tests et développement sur des copies exactes de production
• Conformité aux politiques de sécurité informatique

Caractéristiques du système de sauvegarde Proxmox VE

Proxmox VE offre une solution de sauvegarde complètement intégrée qui présente plusieurs avantages distinctifs :

Sauvegardes complètes uniquement:

• Chaque sauvegarde contient l'intégralité de la machine virtuelle ou du conteneur
• Inclut automatiquement la configuration de la VM/CT et toutes les données
• Pas de gestion complexe de sauvegardes incrémentales ou différentielles
• Simplicité de restauration : une seule archive suffit

Intégration native:

• Utilise les capacités spécifiques de chaque type de stockage
• S'adapte aux différents types de systèmes invités (VM et conteneurs)
• Interface graphique et ligne de commande disponibles
• Gestion centralisée depuis l'interface web

Architecture et stockage des sauvegardes

Types de stockage pour les sauvegardes

Avant de pouvoir effectuer une sauvegarde, il est impératif de configurer un stockage de sauvegarde. Proxmox VE supporte deux approches principales :

Proxmox Backup Server

Le Proxmox Backup Server représente la solution la plus avancée :

Avantages techniques:

• Déduplication de données : Les blocs identiques ne sont stockés qu'une seule fois, économisant considérablement l'espace
• Stockage des métadonnées : Les informations de structure sont séparées des données
• Chiffrement côté client : Sécurité maximale des données sauvegardées
• Vérification d'intégrité : Contrôles automatiques de l'intégrité des sauvegardes

Mise en oeuvre recommandée:

• Déploiement sur un serveur dédié pour optimiser les performances
• Réseau haute vitesse entre Proxmox VE et le Backup Server
• Stockage local rapide sur le serveur de sauvegarde

Stockage de niveau fichier

Alternative plus simple utilisant des systèmes de fichiers classiques :

Options disponibles:

• NFS : Solution réseau éprouvée, facile à mettre en œuvre
• SMB/CIFS : Compatible avec les environnements Windows
• Stockage local : Performance maximale mais pas de protection contre les pannes du serveur

Considérations pratiques:

• Les sauvegardes sont stockées comme des fichiers réguliers
• Possibilité de copie vers bande magnétique pour archivage hors site
• Gestion manuelle de l'espace disque nécessaire

Nomenclature des fichiers de sauvegarde

Proxmox VE utilise une convention de nommage standardisée qui encode des informations importantes :

Format standard:

vzdump-[type]-[vmid]-[date]-[heure].[extension]

Exemple concret:

vzdump-lxc-105-2025_09_08-10_47_09.tar.gz

• lxc: Type de système (conteneur Linux)
• 105: Identifiant numérique de la VM/conteneur
• 2025_09_08: Date de création (8 septembre 2025)
• 10_47_09: Heure de création (10:47:09)
• .tar.gz: Format et compression utilisés

Avantages de cette nomenclature:

• Stockage multiple dans le même répertoire
• Identification rapide du contenu
• Tri chronologique automatique
• Compatibilité avec les scripts d'automatisation

Modes de sauvegarde - Concepts fondamentaux

Le choix du mode de sauvegarde représente un compromis entre la cohérence des données et le temps d'arrêt du service. Proxmox VE propose trois modes principaux, chacun adapté à des besoins spécifiques.

Mode STOP (arrêt) 🛑

Pour les VMs:

1. Arrêt propre : La VM reçoit un signal d'extinction normale
2. Processus QEMU de sauvegarde : Un processus dédié lit les disques virtuels
3. Redémarrage : La VM redémarre automatiquement après le début de la sauvegarde
4. Sauvegarde en arrière-plan : Utilise les capacités de sauvegarde live de QEMU

Avantages	Inconvénients
Cohérence maximale: Aucune écriture pendant la lecture des données	Temps d'arrêt: Service indisponible pendant l'arrêt et le redémarrage
Fiabilité absolue: Pas de risque d'incohérence des données	Durée variable: Dépend de la taille des données et de la vitesse du stockage
Simplicité: Processus linéaire et prévisible

Cas d'usage recommandés:

• Serveurs de base de données critiques
• Sauvegardes de maintenance programmées
• Lorsque les données priment

Pour les conteneurs LXC:

• Arrêt complet du conteneur pendant toute la durée de la sauvegarde
• Temps d'arrêt potentiellement très long selon la taille des données
• Recommandé uniquement pour les petits conteneurs ou les maintenances

Mode SUSPEND (Suspension) ⏸️

Pour les VMs:

important

Ce mode est maintenu pour compatibilité, mais le mode snapshot est généralement préférable car il offre une meilleure performance avec une cohérence similaire.

Pour les conteneurs LXC:

Processus en trois étapes :

1. Première copie rsync :

   • Copie des données vers un répertoire temporaire
   • Le conteneur continue de fonctionner normalement
   • Capture la majorité des données

2. Suspension et synchronisation :

   • Arrêt temporaire du conteneur
   • Deuxième rsync pour capturer les modifications
   • Temps d'arrêt minimal grâce à la pré-copie

3. Reprise et archivage :

   • Redémarrage immédiat du conteneur
   • Création de l'archive finale en arrière-plan

Avantages	Inconvénients
Temps d'arrêt minimal: Seulement pour la synchronisation finale	Espace temporaire requis: Besoin d'un espace supplémentaire pour la copie
Cohérence: Capture un état cohérent du système de fichiers	Performance réseau médiocre: Pour les stockages NFS/CIFS

Mode SNAPSHOT (Instantané) 📸

Le mode snapshot représente le meilleur compromis pour la plupart des cas d'usage en production. Imaginez que vous photographiez un paysage depuis une voiture en mouvement. Le mode snapshot fait exactement cela : il "photographie" les données d'une VM pendant qu'elle continue de fonctionner.

Pour les VMs :

Comment ça fonctionne concrètement:

Étape 1: Installation du surveillant

• La VM fonctionne normalement.
• QEMU installe un « intercepteur » qui surveille tous les disques.
• La VM ne remarque rien et continue son travail.

Étape 2: Processus de copie intelligent

• Le processus de sauvegarde démarre et commence à lire le disque
• La VM continue d'écrire sur le disque en même temps !
• Solution : quand la VM veut écrire sur une zone pas encore copiée, l'intercepteur dit "STOP ! Je copie d'abord l'ancienne version"
• Une fois l'ancienne version copiée, la VM peut écrire la nouvelle

Rôle de l'agent invité (optionnel mais recommandé):

L'agent QEMU permet d'améliorer le processus de sauvegarde en mode snapshopt en maintenant une communication avec l'hperviseur. Voici le flux des étapes d'une sauvegarde dans ce mode avec l'agent QEMU installé:

1. L'agent reçoit le signal: « Prépare-toi pour une sauvegarde ».
2. L'agent dit aux applications: « Videz vos mémoires caches respectives ».
3. L'agent gèle le système de fichiers (2-3 secondes).
4. La sauvegarde démarre avec un état cohérent.
5. L'agent dégèle le système.

Avec Windows

Windows peut avoir plusieurs logiciels qui « gèlent » le système (antivirus, autres sauvegardes). L'agent QEMU coordonne tout cela pour éviter les conflits.

Pour les conteneurs LXC :

attention

Pour les conteneurs, le mode « snapshot » utilise les vraies fonctionnalités de snapshot du système de stockage. Il s'agit donc d'un véritable snapshot et non pas d'une sauvegarde de type snapshot.

Voir cette section pour bien distinguer les deux concepts sans ambiguité.

Compression et optimisation 🗜️

Il est possible (et recommandé) de compresser les sauvegardes de vos machines virtuelles sous Proxmox. Je vous dresse ici les différents formats disponibles, ainsi que leurs caractéristiques respectives:

Algorithme	Format	Caractéristiques
Lempel-Ziv-Oberhumer	LZO	Compression rapide avec faible utilisation CPU Ratio de compression modéré Excellent pour les environnements avec CPU limité Installation par défaut sur la plupart des systèmes
Gzip	GZ	Compression éprouvée basée sur l'algorithme DEFLATE Bon équilibre compression/performance Compatible universellement
Pigz	TGZ	Remplacement de gzip Utilisation de multiples cœurs CPU Accélération significative sur matériel moderne
Zstandard	ZST	Le plus rapide des algorithmes sous Proxmox Parallélisation intégrée (Multithreading) Excellent équilibre taille/vitesse Adoption croissante dans l'industrie

Planification et automatisation 🤖

Création de tâches de sauvegarde

Via l'interface graphique: Datacenter → Backup → Add

1. Serveur spécifique ou tous les nœuds du cluster
2. Destination des sauvegardes
3. Individuelle, par pool, ou toutes
4. Format calendrier similaire à systemd

Options avancées

Bandwith Limit 🕛

Limite l'utilisation de la bande passante I/O ( Attention: La bande passante I/O n'est pas forcémment lié au réseau ). Cela vous permet de ne pas surcharger un stockage partagé entre sauvegardes et machines virtuelles par exemple. Si vous laissez l'option par défaut, il n'y a pas de limite.

Zstd Threads 🤹

Il s'agit du nombre de threads (coeurs logiques) utilisés en parallèles par l'algorithme de compression Zstandard pendant la sauvegarde. Si vous indiquez 0, la moitié des coeurs logiques seront utilisés pour la compression. Par exemple:

Serveur de 4 coeurs

zstd: 0 → Utilise 2 threads (4÷2)
zstd: 1 → Utilise 1 thread
zstd: 4 → Utilise 4 threads

IO-Workers 🚧

Un IO-Worker est un processus qui lit les données du disque dur de la VM pendant la sauvegarde. C'est différent de la compression!

Comment ça fonctionne:

1 Worker (séquentiel):

Lit bloc 1 → Attend compression → Lit bloc 2 → Attend compression...

Timeline : |████|░░░░|████|░░░░|████|░░░░|
            Read Wait Read Wait Read Wait

Résultat: Lent car beaucoup d'attente

4 Workers (parallèle):

Worker 1 : |████|    |████|    |████|
Worker 2 :      |████|    |████|    |████|
Worker 3 :           |████|    |████|    |████|
Worker 4 :                |████|    |████|    |
Timeline : |██████████████████████████████████|

Résultat: Plus rapide car lecture continue

+ de workers ≠ + de performances automatiquement

En regardant les schémas ci-dessus, on aurait tendance à vouloir mettre la quantitée de workers au maximum. Néanmoins, selon les ressources physiques dont vous disposez, cela pourrait être une mauvaise idée. Tout dépend du type de disque(s) dur(s) que vous avez en place pour la sauvegarde.

Exemples de configurations possibles:

Type de stockage	IO-Workers	Facteurs à considérer
NVMe / SSD	32	SSD peut gérer beaucoup d'accès parallèles Pas de tête de lecture physique à déplacer Latence très faible
HDD Mécanique	4	Tête de lecture doit se déplacer physiquement Trop de workers = thrashing (va-et-vient permanent) Performance dégradée avec trop de parallélisme
Stockage réseau	8	Latence réseau Bande passante partagée Capacité du stockage distant

Fleecing 🏎️

Imaginez que vous voulez sauvegarder une machine virtuelle pendant qu'elle tourne et offre des services. Éventuellement, la VM aura besoin de modifier un fichier sur le disque dur en cour de sauvegarde. L'agent QEMU interviendra alors et mentionne qu'il doit d'abord sauvegarder l'ancienne version. Cette sauvegarde de l'ancienne version peut causer un temps d'attente important, surtout si le stockage est externe et/ou lent. Les utilisateurs auront donc l'impression que leur ordinateur virtuel fonctionne mal et/ou est très lent.

La solution ? Une mémoire cache intermédiaire!

Le fleecing permet de déterminer un stockage tampon qui accueillera les fichiers en sauvegarde rapidement pour les relayer vers un périphérique plus lent par la suite.

Gestion de l'espace en Fleecing

Tout comme pour les machines virtuelles, l'espace que vous allouée au fleecing peut employer une stratégie thin provisionning ou thick provisionning

Thin provisionning :

Rien ne vaut un exemple pour rendre ces concepts un peu plus concrets. Disons que nous avons une machine virtuelle avec un poids de 100Go à sauvegarder. L'espace de fleecing commencera à 0Go et grandira selon les besoins. Ces besoins varieront en fonction de la vitesse avec laquelle les données passeont de l'espace de fleecing vers le stockage permanent. Évidemment, l'espace de fleecing ne dépassera jamais la taille de la machine virtuelle à sauvegarder. Une fois la sauvegarde terminé, l'espace de fleecing utilisé pourra être récupéré pour le même objectif dans le cas de la sauvegarde d'une autre VM.

Thick provisionning :

Dans le cas du thick provisionning, c'est assez simple. Si nous avons une machine virtuelle avec un poids de 100Go, cette même valeur sera aussitôt réservée dans l'espace de fleecing et aucune autre machine virtuelle ne pourra y avoir accès.

Scénarios

• L'entreprise possède une infrastructure virtuelle sous Proxmox.
• Un serveur de base de données virtuel tourne à l'intérieur de l'hyperviseur (Poids: 500Go).
• Un disque dur NVMe est aussi présent dans Proxmox pour effectuer du fleecing.
• Les sauvegardes sont stockés à distance sur un NAS.

Sans fleecing :

vzdump 100 --storage nas-backup
# Résultat : Base de données très lente pendant 2h de sauvegarde
# Utilisateurs se plaignent des performances

Avec fleecing :

vzdump 100 --fleecing enabled=1,storage=nvme-local --storage nas-backup
# Résultat : Base de données normale, sauvegarde discrète
# Utilisateurs ne remarquent rien

Ce qui se passe :

1. VM écrit → Ancienne donnée va sur NVMe local (rapide)
2. VM continue normalement
3. En arrière-plan : NVMe → NAS (sans impact sur la VM)
4. Fin sauvegarde : Image de fleecing supprimée automatiquement

Repeat missed 🔁

Une fois activée, cette option indiquera à Proxmox de réessayer une sauvegarde dans le cas ou la sauvegarde initiale aurait échouée pour une raison ou une autre. Cela évite les trous dans la couverture de sauvegarde.

Gestion de la rétention

La rétention définie la durée de conservation des sauvegardes selon différents critères temporels. Proxmox VE offre un système flexible permettant de s'adapter aux besoins métier.

Options disponibles

Keep all backups:

• Conservation de toutes les sauvegardes
• Gestion manuelle de l'espace requis
• Usage temporaire ou environnements de test

Keep Last:

• Conservation des N dernières sauvegardes
• Indépendant de la date de création
• Protection contre les sauvegardes multiples avant maintenance

Rétention temportelle:

• keep-hourly : Dernières N heures (une sauvegarde par heure max.)
• keep-daily : Derniers N jours (une sauvegarde par jour max.)
• keep-weekly : Dernières N semaines (une sauvegarde par semaine max.)
• keep-monthly : Derniers N mois (une sauvegarde par mois max.)
• keep-yearly : Dernières N années (une sauvegarde par an max.)

Exemples avec scénarios

Premier scénario:

Planification: Une sauvegarde, une fois par jour, à 1h00 am.

Options:

• keep-daily: 7
• keep-weekly: 2
• keep-monthly: 1

Dim. 05 Oct. 2025 keep-daily 1	Sam. 04 Oct. 2025 keep-daily 2	Ven. 03 Oct. 2025 keep-daily 3	Jeu. 02 Oct. 2025 keep-daily 4	Mer. 01 Oct. 2025 keep-daily 5	Mar. 30 Sept. 2025 keep-daily 6	Lun. 29 Sept. 2025 keep-daily 7
Dim. 28 Sept. 2025 keep-weekly 1	Sam. 27 Sept. 2025 backup 1:00	Ven. 26 Sept. 2025 backup 1:00	Jeu. 25 Sept. 2025 backup 1:00	Mer. 24 Sept. 2025 backup 1:00	Mar. 23 Sept. 2025 backup 1:00	Lun. 22 Sept. 2025 backup 1:00
Dim. 21 Sept. 2025 keep-weekly 2	Sam. 20 Sept. 2025 backup 1:00	Ven. 19 Sept. 2025 backup 1:00	Jeu. 18 Sept. 2025 backup 1:00	Mer. 17 Sept. 2025 backup 1:00	Mar. 16 Sept. 2025 backup 1:00	Lun. 15 Sept. 2025 backup 1:00
Dim. 14 Sept. 2025 backup 1:00	Sam. 13 Sept. 2025 backup 1:00	Ven. 12 Sept. 2025 backup 1:00	Jeu. 11 Sept. 2025 backup 1:00	Mer. 10 Sept. 2025 backup 1:00	Mar. 09 Sept. 2025 backup 1:00	Lun. 08 Sept. 2025 backup 1:00
Dim. 07 Sept. 2025 backup 1:00	Sam. 06 Sept. 2025 backup 1:00	Ven. 05 Sept. 2025 backup 1:00	Jeu. 04 Sept. 2025 backup 1:00	Mer. 03 Sept. 2025 backup 1:00	Mar. 02 Sept. 2025 backup 1:00	Lun. 01 Sept. 2025 backup 1:00
Dim. 31 Août 2025 keep-monthly 1	Sam. 30 Août. 2025 backup 1:00	Ven. 29 Août 2025 backup 1:00	Jeu. 28 Août 2025 backup 1:00	Mer. 27 Août 2025 backup 1:00	Mar. 26 Août 2025 backup 1:00	Lun. 25 Août 2025 backup 1:00

Deuxième scénario:

Planification: Une sauvegarde, deux fois par jour, chaque 12h.

Options:

• keep-hourly: 4
• keep-daily: 5
• keep-weekly: 2

Dim. 05 Oct. 2025 keep-hourly 1 keep-hourly 2	Sam. 04 Oct. 2025 keep-hourly 3 keep-hourly 4	Ven. 03 Oct. 2025 keep-daily 1 backup 0:00	Jeu. 02 Oct. 2025 keep-daily 2 backup 0:00	Mer. 01 Oct. 2025 keep-daily 3 backup 0:00	Mar. 30 Sept. 2025 keep-daily 4 backup 0:00	Lun. 29 Sept. 2025 keep-daily 5 backup 0:00
Dim. 28 Sept. 2025 keep-weekly 1 backup 0:00	Sam. 27 Sept. 2025 backup 12:00 backup 0:00	Ven. 26 Sept. 2025 backup 12:00 backup 0:00	Jeu. 25 Sept. 2025 backup 12:00 backup 0:00	Mer. 24 Sept. 2025 backup 12:00 backup 0:00	Mar. 23 Sept. 2025 backup 12:00 backup 0:00	Lun. 22 Sept. 2025 backup 12:00 backup 0:00
Dim. 21 Sept. 2025 keep-weekly 2 backup 0:00	Sam. 20 Sept. 2025 backup 12:00 backup 0:00	Ven. 19 Sept. 2025 backup 12:00 backup 0:00	Jeu. 18 Sept. 2025 backup 12:00 backup 0:00	Mer. 17 Sept. 2025 backup 12:00 backup 0:00	Mar. 16 Sept. 2025 backup 12:00 backup 0:00	Lun. 15 Sept. 2025 backup 12:00 backup 0:00
Dim. 14 Sept. 2025 backup 12:00 backup 0:00	Sam. 13 Sept. 2025 backup 12:00 backup 0:00	Ven. 12 Sept. 2025 backup 12:00 backup 0:00	Jeu. 11 Sept. 2025 backup 12:00 backup 0:00	Mer. 10 Sept. 2025 backup 12:00 backup 0:00	Mar. 09 Sept. 2025 backup 12:00 backup 0:00	Lun. 08 Sept. 2025 backup 12:00 backup 0:00

Restauration 👻

Vos sauvegardes peuvent évidemment être restaurés aisément. Voici comment procéder.

Via l'interface graphique

Datacenter → Noeud → VM concerné → Backup

Via l'invite de commandes

qmrestore /var/lib/vz/dump/vzdump-qemu-100-2025_09_09-12_41_17.vma 100 --force

remarque

La machine virtuelle que vous restaurez doit être éteinte.